1. Field
The present application relates generally to executing user-provided computer program code in restricted execution environments, and more particularly to enabling dissemination and execution of user-provided computer program components in security-restricted execution environments such as Web browsers.
2. Related Art
Techniques for executing computer program code in Web browsers are well known. Web pages may include code in a language such as JavaScript™, to be executed when the page is presented to a user in a browser such as the Microsoft® Internet Explorer™ browser, the Mozilla® Firefox® browser, and the like. Code implemented in programming languages such as the Java® language, the Microsoft® Jscript® language, and the Microsoft® C#® language may be downloaded from Internet servers, e.g., web sites, and executed by Web browsers. Some types of code or data, e.g., Adobe® Flash® scripts or Portable Document Format (PDF) documents, may be unsupported, i.e., not executable, by the browser itself, but the browser may be extended with plugins that support such specialized file types. A plugin is, for example, a computer program code module that is invoked by the browser (or other application) and may use the browser's features to display information, receive input, transfer data over a network, and the like. A plugin provides specialized features and is ordinarily activated, e.g., loaded from disk and initialized by the browser, in response to receipt of web content of a type associated with the plugin. Plugins are implemented in a programming language, e.g., C or C++, for which the browser provides a plugin Application Programming Interface (API). Unlike script code, e.g., JavaScript, which is executed by the browser in a secure environment that prevents code downloaded from the Internet from performing sensitive system operations such as accessing files and opening network connections to remote computers, the code that implements a plugin is ordinarily native code executable by the computer's processor. Such native code is not subject to the same level of security restrictions as browser-executed script code, and may perform sensitive system operations, potentially resulting in unauthorized data access or breaches of system security. Therefore, use of a plugin from an unknown or untrusted source is discouraged, and users are unlikely to use plugins provided by relatively unknown vendors. Furthermore, creating a browser plugin is a relatively difficult and expensive undertaking for several reasons. For example, security issues must be identified and resolved. Further, a relatively difficult to use, platform specific programming language is used by many browsers for plugin development, platform specific versions of the plugin are created and distributed for each type of platform (e.g., the Microsoft Windows® operating system, the Apple® Mac OS operating system, the Linux® operating system, and the like) to be supported by the platform, browser-specific version of the plugin may need to be created and distributed for each type of browser supported by each platform, e.g., Internet Explorer on Windows, FireFox on Windows, FireFox on Mac OS, and the Safari® browser on Mac OS.
As introduced above, because of the potential harm that may be caused by program code that has unrestricted access to a computer's resources, security restrictions are imposed on code executed by the Web browser, particularly if the code is from an unknown or un-trusted server. For example, most Web browsers place restrictions on the ability of downloaded code to access files, networks, operating system interfaces, storage devices, and other resources. Code executed on a client computer by a browser, such as downloaded code, is subject to tighter security, because such code could delete files, improperly use system resources, retrieve information stored on the computer, search the computer for security vulnerabilities, present requests to the user for sensitive information (phishing), install a virus on the computer, use the computer to attack or spread the virus to other computers, and so on. Therefore, Web browsers such as Internet Explorer do not allow code from un-trusted servers to execute unless permission is granted by the user.
Many existing browser-based runtime environments for executing downloaded code, such as Java applets, ActiveX™ controls, and Firefox extensions, ask the user for blanket permission to run and access any system resource. ActiveX controls are computer program code modules that can be embedded in a web page and executed by Internet Explorer when the web page is accessed, i.e., downloaded from a web server 100. When code such as an ActiveX control is downloaded as part of a web page and attempts to execute in the Internet Explorer browser, the browser displays a warning message to the user, and prevents execution of the entire control unless the user explicitly allows or approves execution of that control, or, in other examples, unless the user explicitly allows execution of code from that server or that server's network domain. Once the user approves execution of the control, the control may access a wide range of system resources.
Other existing runtime environments, such as the Microsoft Windows Vista® operating system, offer a level of security granularity that has little meaning to an end user, e.g., by asking the user for permission to read files. Some programming languages, such as Java, permit downloaded code scripts to access restricted resources on the computer using security credential information, e.g., digitally-signed certificates. However, the security credentials of downloaded code are exposed to the user, and the user is often responsible for maintaining the credentials, e.g., updating them when they expire and keeping them confidential. Furthermore, certain system resources such as special-purpose devices may not be available to programs written in the web programming language being used (such as JavaScript or Java) even if permission is available, because the language lacks an interface to those resources. Such resources can be accessed via a “native” programming language such as C++, but communication between a native language and a web programming language is complex, and existing web programming frameworks do not provide features for integrating native programs with browser-based web applications.
These security restrictions diminish the ability of applications developed in existing web programming frameworks to provide a rich user interface that matches user interfaces provided by native applications in terms of system resource access and other features. Existing frameworks provide rudimentary security features that are complex and place the burden of ensuring security on the application developer. It would be desirable, therefore, to have a programming framework that allows programmers to quickly and easily develop web applications that safely and securely access security-sensitive system resources.